enhance: add support for selection questions in group activities & grading and extend corresponding test suite #4446
Conversation
…nd improve element instance seeding logic
📝 WalkthroughWalkthroughThis pull request introduces comprehensive support for a new Changes
Possibly related PRs
Suggested reviewers
Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/frontend-pwa/src/components/groupActivity/GroupActivityStack.tsx (1)
284-291: Consider optimizing the accumulator spread operation.The implementation correctly handles selection responses during submission. However, using the spread operator on the accumulator in the reducer can lead to O(n²) time complexity.
Consider this optimization:
- return { - ...acc, - [decision.instanceId]: { + acc[decision.instanceId] = { type: decision.type, response: decision.selectionResponse ?? undefined, valid: true, - }, - } + } + return accpackages/graphql/src/ops.schema.json (1)
8458-8477: LGTM! Consider adding field documentation.The type structure for
selectionResponseis well-defined using appropriate GraphQL types. The use of a non-null list of integers is a good choice for representing selected options.Consider adding a description to document:
- The purpose of this field
- The meaning of the integer values (e.g., do they represent indices or IDs?)
- Any constraints on valid values
{ "name": "selectionResponse", - "description": null, + "description": "List of selected option indices/IDs for a selection question response", "args": [], "type": {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
apps/frontend-manage/src/components/courses/groupActivity/GroupActivityGradingStack.tsx(3 hunks)apps/frontend-manage/src/pages/courses/grading/groupActivity/[id].tsx(1 hunks)apps/frontend-pwa/src/components/groupActivity/GroupActivityStack.tsx(2 hunks)cypress/cypress/e2e/J-group-activity-workflow.cy.ts(10 hunks)packages/graphql/src/graphql/ops/MGradeGroupActivitySubmission.graphql(1 hunks)packages/graphql/src/graphql/ops/QGetGradingGroupActivity.graphql(1 hunks)packages/graphql/src/graphql/ops/QGroupActivityDetails.graphql(1 hunks)packages/graphql/src/ops.schema.json(1 hunks)packages/graphql/src/public/client.json(3 hunks)packages/graphql/src/public/schema.graphql(1 hunks)packages/graphql/src/public/server.json(3 hunks)packages/graphql/src/schema/groupActivity.ts(1 hunks)packages/graphql/src/services/groups.ts(2 hunks)packages/prisma/src/data/helpers.ts(11 hunks)packages/prisma/src/data/seedTEST.ts(9 hunks)
✅ Files skipped from review due to trivial changes (2)
- apps/frontend-manage/src/pages/courses/grading/groupActivity/[id].tsx
- packages/graphql/src/public/client.json
👮 Files not reviewed due to content moderation or server errors (4)
- packages/graphql/src/graphql/ops/QGetGradingGroupActivity.graphql
- packages/graphql/src/graphql/ops/QGroupActivityDetails.graphql
- packages/graphql/src/public/schema.graphql
- packages/graphql/src/public/server.json
🧰 Additional context used
🪛 Biome (1.9.4)
apps/frontend-pwa/src/components/groupActivity/GroupActivityStack.tsx
[error] 127-127: Avoid the use of spread (...) syntax on accumulators.
Spread syntax should be avoided on accumulators (like those in .reduce) because it causes a time complexity of O(n^2).
Consider methods such as .splice or .push instead.
(lint/performance/noAccumulatingSpread)
⏰ Context from checks skipped due to timeout of 90000ms (8)
- GitHub Check: cypress-run
- GitHub Check: build
- GitHub Check: build
- GitHub Check: SonarCloud
- GitHub Check: build
- GitHub Check: test
- GitHub Check: check
- GitHub Check: Analyze (javascript)
🔇 Additional comments (12)
packages/graphql/src/schema/groupActivity.ts (1)
102-102: LGTM! The schema change aligns with the PR objective.The addition of
selectionResponsefield toGroupActivityDecisiontype enables support for selection questions in group activities.apps/frontend-pwa/src/components/groupActivity/GroupActivityStack.tsx (1)
125-133: LGTM! Selection type handling is properly implemented.The implementation correctly processes selection responses in the
useEffecthook, maintaining consistency with other element types.🧰 Tools
🪛 Biome (1.9.4)
[error] 127-127: Avoid the use of spread (
...) syntax on accumulators.Spread syntax should be avoided on accumulators (like those in
.reduce) because it causes a time complexity ofO(n^2).
Consider methods such as .splice or .push instead.(lint/performance/noAccumulatingSpread)
apps/frontend-manage/src/components/courses/groupActivity/GroupActivityGradingStack.tsx (3)
118-125: LGTM! FreeText type handling is properly implemented.The implementation correctly processes free text responses in the
findResponsefunction, maintaining consistency with other element types.
126-133: LGTM! Selection type handling is properly implemented.The implementation correctly processes selection responses in the
findResponsefunction, maintaining consistency with other element types.
233-233: Document the purpose of the preview prop.The
previewprop has been added to theStudentElementcomponent without clear documentation of its purpose or impact.Please clarify:
- What is the purpose of this prop?
- How does it affect the component's behavior?
- Are there any side effects to consider?
packages/prisma/src/data/helpers.ts (2)
341-341: LGTM! ActivityType parameter is properly added.The
activityTypeparameter is correctly added to the function signature, enabling activity-specific behavior.Also applies to: 351-351
369-372: Document the rationale for different reset times.The implementation sets different
resetTimeDaysvalues based on element types:
- Flashcards: 7 days (single), 6 days (all)
- Questions: 5 days (single), 8 days (all)
- Content Elements: 7 days (single), 6 days (all)
- Mixed Stack: 5-6 days
Please clarify:
- Why are different reset times used for different element types?
- Is there a specific learning theory or requirement behind these values?
- Should these values be configurable or defined as constants?
Also applies to: 404-407, 439-442, 476-479, 516-519, 563-566, 606-609, 631-634
packages/prisma/src/data/seedTEST.ts (1)
1327-1327: LGTM! Consistent activity type assignments.The addition of
activityTypefield across all stack creation calls ensures proper categorization of activities.Also applies to: 1367-1367, 1408-1408, 1461-1461, 1507-1507, 1549-1549, 1593-1593, 1637-1637
cypress/cypress/e2e/J-group-activity-workflow.cy.ts (2)
16-28: LGTM! Well-defined test constants.The constants for selection questions are clearly defined with appropriate test data.
551-556: LGTM! Comprehensive selection interaction testing.The test properly verifies the selection UI interactions with multiple fields.
packages/graphql/src/services/groups.ts (1)
1547-1554: Verify error handling in selection response processing.While the selection response handling is implemented correctly, consider adding explicit error handling for:
- Invalid selection indices
- Missing selection responses
- Duplicate selections
✅ Verification successful
Error handling in selection response processing is comprehensive and secure.
The implementation includes proper validation for:
- Missing or invalid selection responses
- Type checking of selection indices
- Safe handling of missing/invalid indices
- Graceful fallback for error cases
The current error handling approach is sufficient and follows defensive programming practices.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for error handling patterns in selection processing rg -A 5 "try.*catch.*selection|throw.*selection|error.*selection" .Length of output: 87222
Script:
#!/bin/bash # Search for updateSelectionResults implementation and surrounding context ast-grep --pattern 'function updateSelectionResults($$$) { $$$ }' # Search for selection validation patterns rg -A 5 "selection.*invalid|invalid.*selection|selection.*error" .Length of output: 89012
packages/graphql/src/graphql/ops/MGradeGroupActivitySubmission.graphql (1)
16-16: LGTM! Schema extension follows existing pattern.The addition of selectionResponse field maintains consistency with other response types in the schema.
|
|
||
| // create answer collection | ||
| cy.get('[data-cy="resources"]').click() | ||
| cy.createAnswerCollection({ | ||
| name: SECollection, | ||
| description: SECollectionDescription, | ||
| entries: SECollectionOptions, | ||
| access: messages.manage.resources.accessPRIVATE, | ||
| accessCy: 'private', | ||
| }) | ||
|
|
||
| // create selection question | ||
| cy.get('[data-cy="library"]').click() | ||
| cy.createQuestionSE({ | ||
| title: SEQuestionTitle, | ||
| content: SEQuestion, | ||
| numberOfInputs: SEQuestionInputs, | ||
| collectionName: SECollection, | ||
| correctAnswers: SECollectionOptions.filter((_, i) => | ||
| SECollectionSolutions.includes(i) | ||
| ), | ||
| }) |
There was a problem hiding this comment.
💡 Codebase verification
Edge case testing is indeed missing from selection question creation tests
Current tests only cover the happy path with a fixed input size of 3. Consider adding the following test scenarios:
- Boundary conditions: Test with 0, 1, and maximum allowed inputs
- Invalid inputs: Test handling of invalid selection counts
- Empty collections: Verify behavior when the answer collection is empty
- Duplicate selections: Ensure proper handling of duplicate answer selections
🔗 Analysis chain
Verify test coverage for edge cases in selection question creation.
While the basic creation flow is tested, consider adding tests for:
- Maximum/minimum number of inputs
- Duplicate selections
- Empty collection handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing edge case tests
rg -A 5 "SEQuestionInputs.*=.*[01]|SEQuestionInputs.*=.*100" cypress/
rg "duplicate.*selection|empty.*collection" cypress/
Length of output: 126
Script:
#!/bin/bash
# Find all SE (Selection Element) related test files and patterns
echo "=== Selection Element Test Files ==="
fd ".*\.cy\.ts$" cypress/ --exec rg -l "createQuestionSE|SEQuestion"
echo -e "\n=== Test Data Definitions ==="
rg "SEQuestion.*=.*{" -A 5 cypress/
echo -e "\n=== Validation Patterns ==="
rg "validation|invalid|error.*SEQuestion" cypress/
echo -e "\n=== Test Constants ==="
rg "const.*SEQuestion" -A 3 cypress/
Length of output: 2553
Script:
#!/bin/bash
# Check createQuestionSE implementation
echo "=== Question Creation Implementation ==="
rg -A 10 "createQuestionSE.*=.*{" cypress/
echo -e "\n=== Command Implementation ==="
rg -A 10 "commands.*createQuestionSE" cypress/
Length of output: 369
Script:
#!/bin/bash
# Search for implementation with fixed pattern
echo "=== Custom Command Implementation ==="
rg "createQuestionSE" cypress/support/
echo -e "\n=== Type Definitions ==="
fd -e ts -e d.ts cypress/ --exec rg "interface.*Question|type.*Question"
Length of output: 658
klicker-uzh
|
||||||||||||||||||||||||||||
| Project |
klicker-uzh
|
| Branch Review |
selection-group-activities
|
| Run status |
|
| Run duration | 14m 58s |
| Commit |
|
| Committer | Julius Schlapbach |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
203
|
| View all changes introduced in this branch ↗︎ | |
Summary by CodeRabbit
Release Notes
New Features
Improvements
Technical Updates